package com.coderman.infosys.auth.api.facade.authority;

import com.coderman.infosys.plat.auth.common.dto.PageDTO;
import com.coderman.infosys.plat.auth.common.dto.ResultDataDto;
import com.coderman.infosys.auth.api.dto.authority.AuthorityDTO;


/**
* @Description:接口
* @Author:
* @CreateTime:2022-01-02 15:27:39
* @version v1.0
*/
public interface AuthorityQueryFacade{

	/**
	 *
	 * @Description 判断用户有没有访问某系统的权限
	 * @param userId
	 * @param systemCode
	 * @return AuthorityDTO
	 *
	 * see AuthPlatQueryAPI
	 */
	@Deprecated
	ResultDataDto<AuthorityDTO> checkUserSystemAuth(Long userId, String systemCode);

	/**
	 *
	 * @Description 根据用户和系统获取系统权限信息
	 * @param userId
	 * @param systemCode
	 * @return AuthorityDTO
	 */
	@Deprecated
	ResultDataDto<AuthorityDTO> getUserSystemAuth(Long userId, String systemCode);

	/**
	 *
	 * @Description 根据权限code获取权限信息
	 * @param authCode
	 * @return AuthorityDTO
	 *
	 * 这里是直接返回聚合根的整体信息，我们讨论一种更具体的情况，也就是说当我们接到需求的时候如果常规做法就是每个表或者每个操作来定义一个读或者写接口，
	 * 那就是说在用户界面上因为交互PRD和预先进行接口定义的情况下我们可能很容易的被带入了面向API和页面编程的坑里面，由于API的明确性所以并没有太多考虑模型和聚合层面的因素
	 * 因此这种通过聚合根标示返回整个聚合范围内对象的接口可能就会被各个具体聚合根内部对象的访问接口替代掉，从而变得分散，那继续看一下下面的情况，
	 * 如果因为性能问题这个聚合根比较大，此时这个接口是否还合理，比如因为交互的问题理论上可以一个接口提供全部数据，但是交互操作需要多步
	 * 或者说因为其聚合情况下不合理导致查询内部会查询历史信息，但是实际上不需要，那么这个接口是否还合理。
	 *
	 * 所以就上面的分析看，如果按照领域去做的话查询接口可能也不会太少，但是会变得更加聚合，同时查询场景也会变得丰富，对于接口设计能力也有很大要求，
	 * 如何在聚合层面设计兼容性和灵活性更好的接口很有挑战。
	 */
	ResultDataDto<AuthorityDTO> getByCode(String authCode);

	/**
	 *
	 * @Description 分页获取权限信息
	 * @param pageDTO
	 * @return PageDTO<AuthorityDTO>
	 */
	ResultDataDto<PageDTO> getPageList(PageDTO pageDTO);
}